This lesson examines some broad configuration topics. Further detail on configuring specific services and options are contained in other units. To ensure each student’s screenshots are coming from their lab VM, begin by changing your system’s hostname from pc12345678
to pcNNNNNNNNN
where NNNNNNNNN
is your student number. Your screenshots will then show the hostname in the shell prompts so I can verify your work was done on your machine. Submissions which do not have your student number in your hostname showing in the shell prompts will not be marked.
you can change the hostname using the following command:
# Replace NNNNNNNN with your StudentID hostnamectl set-hostname pcNNNNNNNN
# Replace NNNNNNNN with your StudentID
hostnamectl set-hostname pcNNNNNNNN
Then verify that the hostname is set correctly and consistently:
hostnamectl hostname cat /etc/hostname # The following file may need to be edited manually: cat /etc/hosts
hostnamectl
hostname
cat /etc/hostname
# The following file may need to be edited manually:
cat /etc/hosts
The unattended-upgrades service uses a configuration file that contains runtime settings and rules. If you change the configuration, you need to restart the service. How much and whether to use the service is a topic for debate on servers, but it should be run on desktops at a minimum.
Install and enable the unattended-upgrades package if you need to. Also, install the mailutils
package if necessary to allow for local email progress reporting.
sudo apt install unattended-upgrades mailutils sudo dpkg-reconfigure unattended-upgrades
sudo apt install unattended-upgrades mailutils
sudo dpkg-reconfigure unattended-upgrades
Modify the configuration of the unattended-upgrades
package to send emails when doing upgrades. Look for email-related settings. They are about halfway through the config file. Send an email to the local student
user account whenever there are changes made by the upgrade service. Restart the service after you make changes so they take effect.
sudo vi /etc/apt/apt.conf.d/50unattended-upgrades sudo systemctl restart unattended-upgrades
sudo vi /etc/apt/apt.conf.d/50unattended-upgrades
sudo systemctl restart unattended-upgrades
Review the contents of the unattended-upgrades
log files to see what gets logged there.
sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Tip: To verify your configuration and troubleshoot unattended-upgrades
, you can manually trigger the utility in debug mode (using -d
switch): sudo unattended-upgrade -d
. You should receive the email immediately.
Check the Grading section for the required screenshots.
There are multiple ways to determine which services are running, but the decisions about which ones need to be running are based on the system’s intended functions and any organizational policies that may apply.
Identify services which are managed by systemd
systemctl -t service
systemctl -t service
For every service listed that is unfamiliar, you might need to use systemctl, apt-cache, and dpkg to get information about that service. You may find that the service name is a package name. You may have to find which package installed the daemon programs a service has running. You may need to do some research online to learn enough about an unfamiliar package to know if it needs to be on your system.
Check which ports are listening for connection or have outbound connections established. netstat
or ss
are good tools for this.
sudo netstat -tulpn sudo netstat -tupn
sudo netstat -tulpn
sudo netstat -tupn
If there are listening ports or outbound connections that you are not expecting based on the services you expect to be running, you could start investigating based on the process that has the port or connection open.
Whether you identify a process of interest through a service investigation or a connection investigation, the simple process name may not be very helpful in identifying the service it came from.
ps -c PID
to get more info on a running process.Perform this activity for the service listening on port tcp/25.
sudo netstat -tlpn sudo ss -tlpn ps -c <PID-of-process-listening-on-port-tcp-port-25> dpkg -S <pathname-of-process-command> debsums <process-command-package> | grep <pathname-of-process-command>
sudo netstat -tlpn
sudo ss -tlpn
ps -c <PID-of-process-listening-on-port-tcp-port-25>
dpkg -S <pathname-of-process-command>
debsums <process-command-package> | grep <pathname-of-process-command>
Run systemd-analyze
security in both summary mode, and specifically for a service to see what it gives you.
systemd-analyze security systemd-analyze security hddtemp
systemd-analyze security
systemd-analyze security hddtemp
Please refer to the Grading section. You will be using the above tools to investigate one service that is running.
Many times, user accounts exist which were automatically created, but are not needed. Unwatched accounts are a target for crackers. Accounts which own nothing in the filesystem, and have no running processes are usually either end-user accounts, application accounts, historical accounts, or reference accounts.
#!/bin/bash # this script display a list of users from the passwd file who own no files for user in `cut -d : -f 1 /etc/passwd`; do find / -ignore_readdir_race -user $user -ls -quit | grep -q $user || echo $user done
#!/bin/bash
# this script display a list of users from the passwd file who own no files
for user in `cut -d : -f 1 /etc/passwd`; do
find / -ignore_readdir_race -user $user -ls -quit | grep -q $user || echo $user
done
This example of setting resource limits sets limits on interactive system users. As such, it requires the limits to be set at login, and use the PAM library to do it.
Lynis is a tool which can be used for system examination but is also very useful for hardening activities. Along with identifying things that are not in a typical state, it can make many recommendations regarding insecure configurations. This can be helpful when you have a system running software you may not be familiar with. Follow the steps in this lab to install, update, and run Lynis. A current version of Lynis running properly and using it to fix at least one thing is part of the mark for this lab.
Add the lynis community repo to your apt configuration.
Run apt update
and install lynis
to ensure you have the latest version. If you already had lynis
installed, do apt upgrade
instead of install.
Run lynis
in system audit mode.
sudo lynis audit system
sudo lynis audit system
How many suggestions did it give you? Review the warnings.
Choose one issue from the list of issues it shows that is related to access security and modify your configuration to eliminate or mitigate the exposure.
Re-run lynis
and verify it no longer complains about the fixed issue.
Submit your results and screenshots as per instructions posted on Blackboard. Everywhere there is a screenshot marker in the instructions, you must capture enough to show the command you ran and the results of running it.
unattended-upgrades
. Include a screenshot of the email. You can use the mailx
tool to read email for a screenshot.netstat
and ss
to find the process, ps
to find the executable, dpkg
to find the package, and debsums
to validate that the executable is legitimate. Include screenshots showing this process on your system.lynis
you have and a warning from lynis
for a specific item you can fix, and one screenshot showing the subsequent output showing it is no longer a concern after you have fixed it.